【レポート】Leading beyond line of sight: Amazon’s two-pizza teams #INO204 #reinvent
はじめに
こんにちは、かみとです。
re:Inventに現地参加しています。
始めての現地参加なので挙動不審です。
Amazonの元CEOジェフ・ベゾスの言葉とされているtwo-pizza teamについてのセッションがあると聞いてこれは聞かなくてはということで、参加してきました。
予約してなかったので45分前から並びましたがなんとか前から2列目を確保。いい位置で聞くことができました。
※two-pizza teamについてはこちら
登壇者
- Speaker：Daniel Slater, Worldwide Head, Culture of Innovation, AWS, Amazon Web Services, Inc.
- Session level：200 - Intermediate
- Session type：Breakout Session
セッション概要
Accelerating innovation in the cloud and inventing ahead of cuntomers’ rapidly changing demands is crucial. It requires C-suite and line of business to have the right team structure, capabilities, and culture —and right leaders—-to foster innovation from all edges of their organization and realize their digital innovation vision. Join this session to learn how Amazon and AWS use thier two-pizza team model—small, autonomous, and agile teams that they create, Dive deep to learn how Amazon’s two-pizza team are structured and led, and discover the mechanisms that can help ensure accountability, speed, communication, governance, and more.
クラウドにおけるイノベーションを加速させ、急速に変化する顧客の要求に先駆けて発明することは、非常に重要です。そのためには、組織のあらゆる側面からイノベーションを促進し、デジタル・イノベーションのビジョンを実現するための適切なチーム構造、能力、文化、そして適切なリーダーが、経営幹部と事業部門に求められます。 本セッションでは、アマゾンとAWSがどのように2ピザチームモデル（小規模で自律的なアジャイルチーム）を構築しているのか、またアマゾンの2ピザチームがどのように構成され主導されているのか、さらに説明責任、スピード、コミュニケーション、ガバナンスなどの確保に役立つメカニズムを深く学びます。
セッション内容
前置き
- AmazonとAWSの社員全員が速いペースでイノベーションを推進できる組織を実現している。
- なぜこのような組織になっているのか、その大きな文化的背景を概観した後、チームの運営方法や、先ほど述べたようなAmazonとPizzaのチームの違いについて深く掘り下げ、これらのチームが、顧客をすべての行動の中心に据え、スケールとスピードで運営するための具体的なメカニズムを紹介していく。
- しかしこれは、AmazonやAWSでうまくいった方法ですが、これがベストな方法というわけではなく、チームの作り方などには欠点もある。
- 私たちがどのようにチームを形成し、どのようにチームを率いているか、そして私たちが使っている具体的なメカニズムのいくつかを共有したい。
- イノベーションにはいろいろなものがあり、実際に素晴らしいイノベーションが数多く生み出されているが、役に立たない不要なイノベーションもあるのも事実。
- 例えば、雨が降っているときに靴に傘をつけるのが本当に役に立つか？おそらく、防水性と耐久性に優れた靴の素材を作り、それを靴以外の機能や製品に展開する方が、より優れた破壊的なアプローチと言える。
- これは、ロケットサイエンスではなく、人材やツール、文化に起因するもの。
- 1997年当時、Amazonは全てのビジネスロジックのコードをモノリシックなアーキテクチャを採用していた。
- 2000年頃、このモノリシックなアーキテクチャを分解し、今で言うところのマイクロサービスに落とし込んでいった。
- すべてを一元管理するのではなく、注文、在庫、顧客情報などをマイクロサービスのネットワークとして構築し始めた。
- この新しいサービスを信じられないほど早く立ち上げることができるようになった。
- このマイクロサービスの構造はメルビン・コンウェイが提唱した「コンウェイの法則」の概念と一致する。
- チームとその運営方法を根本的に変えることが、優れたアーキテクチャを生み出しお互いに有効に作用するために必要。
- ここではtwo-pizza teamに集約してアーキテクチャを細分化した方法と、その原動力となった文化について掘り下げる。
リーダーシップ原則
- AmazonやAWSの社員全員が一般的な用語としてこのリーダーシップ原則を形成している。
- リーダーシップ原則が定着していることで、正しいコンセプトを導入し判断しなければならない事柄について深く洞察することができる。
- 本当に顧客が求めるものか、ペインポイントを解決するために最良な判断かどうかにフォーカスし、意思決定のスピードを迅速にする。
- 原則「発明と簡素化」について
- お客様の生活や、お客様が本当に愛する他の製品や機能からインスピレーションを受け、それを元お客様にに代わってより大きな問題を解決する手助けをしたいと考える
- 全てを知ったつもりにならず、革新的なイノベーションを起こす方法を探りつづける
- 原則「質素と倹約」について
- 予算も人数も、サイズも、リソースも無制限のチームなどない。
- あえてチームの規模を小さくするという倹約の要素に注目することで、チームは既成概念にとらわれず自己革新を図らなければならない。
- two-pizza teamのチーム構造で迅速に行動するという考え方には、リーダーシップ原則が重要。
two-pizza teamの核となる考え方
- 一つは、サービスのオーナーシップを育てるということ。
- 10人以下という規模は、スピードと顧客に対するオーナーシップを高めるのに非常に有効。
- できるだけお客様の近くにいて、自分たちが見ているものを本当に理解する。
- データだけでなく、お客様のストーリーなども参考にして、イノベーションの原動力にする。
- もう一つは、チーム内に自律性をもたせることも重要。
- エンド・ツー・エンドの体験を自分事にする。
- 自律性、スピード、オーナーシップを育むためにとっているアプローチは、モノリシックアーキテクチャをマイクロサービスに集約したときのメリットそのままを再現している。
- チームは顧客に代わって専門家となり、顧客に何が起こっているのかを素早く把握するだけでなく、顧客に変わって新しい発明をすることができる。
- ただ作るだけでなく、自分のものにする。
- ３つ目は、倹約によるイノベーションの推進。
- どうすればもっとシンプルに物事を進められるか？
- どうすれば顧客のために速く動けるか？
- を常に考えることが重要
two-pizza teamの欠点
- しかし、two-pizza teamも完璧ではないので、欠点もある
- 一つは、チームをどう組織化するかという点
- 複数のチームで相互運用する必要があるケース
- 古典的な文献では、ほとんどが機能指向か製品指向の形をとる。
- どうすれば一緒になって横断的にクールな機能が作れたら素晴らしいかという思いはある。
- しかしこれには時間がかかるし、自分の機能開発に集中することが難しくなる。
- なので、two-pizza teamではコミュニケーションを意図的に最小限に抑えることで対応した。
- しかし時にはマトリクス的に引き戻し、共通点を模索することもある。
- こうして意図的なトレードオフを行いながらチームの組織化を図っている。
- もう一つは、two-pizza teamが全てのケースに適しているとは限らないという点
- 例えば、マーケティングや法務などは、構造がそもそも違う。
- もう一つは、重複して作業を行うリスクがあるという点
- 2つのチームが同じようなことに取り組む可能性が出てくるが、これは意図的に決定された妥協点。
- 「数学的な意味は確かにわかるけど、何が言いたいんだ？顧客の問題に対して、何もしないよりは、2つの機能的な答えがあるほうがいい。」
- チームの顧客重視の姿勢と迅速な行動力を維持するために、時には重複したアプローチも必要です。
チームの内部構造について
- 単一スレッドオーナーシップ（Single-thread ownership）
- Amazonのチームで最も一般的な性質
- 単一の顧客セットと単一の製品または機能にフォーカスする。
- そうすることでロードマップが混雑することはない。
- リソースについても今必要なものだけでなく、将来を見通した上で成長に合わせて変更すべきものを確保する必要がある。
- two-pizza teamがすべてを一つのチームにカプセル化する。
- 単一スレッドリーダーチーム（Single-thread readers）
- AWSのアイデンティティ・アクセス管理（identity and access management）やイオン（ions）のビジネスがそうです。このチームでは、製品や機能セットだけでなく、それを取り巻くすべてのガバナンス、安全性の確保、更新、ロードマップの一貫性などのすべてをビジョンも含めて所有する。
two-pizza teamのナラティブ・アプローチ
- ITチームにおける深い洞察のための具体的なプラクティスとして、ナラティブを使ったアプローチがある。
- パワーポイントの資料に代わって、戦略的文書、オペレーション文書、新規立ち上げ文書の３つの文書をつくる。
- 戦略的文書
- プレスリリースやFAQの文書をつくる
- これをすることで、お客様の立場に立って、これがどのようなものかを想像することができる。
- オペレーション文書
- エラー修正と呼ばれるもので、失敗により顧客への影響がどのようなものであるかを知る。
- 失敗を名指して非難するためのものではない。
- サービスの裏側を知り、ビジネスにとって何が起きて、何が悪かったのかを話し合う。
- 2015年の株主通信でジェフ・ベゾスは「失敗と発明は切っても切れない双子のようなもの」と話している。
- 誰が、何を、いつ、どこで、なぜ、サービスで何がうまくいかなかったのか、その影響はどのようなものだったのかを、トヨタの「なぜなぜ５回」のように問い続ける。
- （３つ目の新規立ち上げ文書？については不明）
失敗から学ぶ耐障害性
- エラー修正による失敗からの学びは他のプロダクトにおいても有効となる。
- サービス開始前に３つの側面から掘り下げる。
- １つ目はサービスのアーキテクチャについて
- サービスを顧客に提供するために必要なAPIやその他のサービスの全体マップを作成する。
- これにより、システムに内在する依存関係を呼び出し、アーキテクチャ上何が必要なのか、冗長性と堅牢性を確保するために何を構築する必要があるのか、必要なエスカレーション・パス、誰が何を所有するのか、などを理解することができる。
- ２つ目は、リリース品質と手順について
- 一度リリースしたものを再度リリースする際の仕組み。
- コード変更の際のデプロイの仕組みや承認経路。
- 自動ロールバックについて。など。
- ３つ目は、インシデントとイベントの管理について
- 何か問題が発生したときのアラート、トレーニングやオンコールシステム。
- イベント測定のための測定基準。
- 測定できない場合どうするのか。
- これらの要素をどのように組み合わせ、人、プロセス、ツールを、どのように、そしてなぜこのように組織化するのか、欠点は何かを時間をかけて考える必要がある。
まとめ
Amazon、AWSのtwo-pizza teamについて実際にそれを運用する責任者のセッションをライブで聞くことができました。
two-pizza teamとAWSリーダーシップ原則との関わり、そして実際にAmazonの裏側をマイクロサービス化した際のチーム構造がコンウェイの法則そのもののように、システムを変えるためにまず組織構造から変えていくというトップダウンの決断力はすごいです。
現場は変えたがってるけどなかなか上層に理解されなかったり、逆にトップはめちゃめちゃやる気だけど現場がしがらみによって動けないなど、なかなか思ったとおりには行かないことが多いとは思いますが、実際にこうしてトップも現場も変わり続けながらイノベーションを起こし続けている、AWSの強さを垣間見た気がします。
そして失敗に対して許容しつつも真摯に向き合う姿勢を強く感じました。
失敗を前向きに捉えようという話は、得てして無責任な空気を含んでしまうことがあると思いますが、失敗を大切に扱うということはその失敗から汲み取れる情報を全て吸い尽くすような、ストイックな向き合い方をすることで最大限に活かされてくるのだということを改めて思いました。
